ADCS
Table of content
Overview
The Active Directory Service or ADCS is a server role used to build a PKI in a Microsoft environment.
The ADCS will be used to provide public key cryptography, digital certificate and signature.
These certificates can be used for different application such as VPN, mail encryption, access control etc...
The ADCS can improve the security of the IS but any misconfiguration induce risks and an attacker can exploit it to fully compromise the domain.
Certify
Certify is a tool that can be used to inspect and exploit ADCS configuration.
Finding ADCS in a huge domain can be timeconsuming. Certify can automatize the discovery of ADCS CA:
.\Certify.exe cas
It will thus print the ROOT CA, the Enrollement CA and the certificate templates.
Certificate templates
Certificate templates are used to speed up the deployement. They are designed to be duplicated and configured depending on the needs.
Some misconfiguration on these tempaltes could allow an attacker to retrieve a certificate he should not be able to get.
Certify automate the discovery of misconfigured templates:
.\Certify.exe find /vulnerable
If the user you control has WriteOwner, WriteDacl or WriteProperty on the certificate, it can be abused.
It is interesting to target certificates with Client Authentication uses.
Once a vulnerable template is found, it can be request using Certify. The following command is an example, parameters may change depending on the certificate:
.\Certify.exe request /ca:${caName} /template:${templateName} /altname:${userToImpersonate}
Once the certificate is generated, it can be converted in PFX format:
openssl pkcs12 -in ${certFilePath} -keyex -CSP "Microsoft Enhanced Cryptographic Provider v1.0" -export -out cert.pfx
The certificate is ready to be used.
If the certificate is an Authentication Certificate, it is possible to request a TGT using Rubeus:
.\Rubeus.exe asktgt /user:${impersontedUser} /certificate:${base64PFX} /password:${pfxPassword} /nowrap
ADCS HTTP Endpoint
The ADCS servers can expose an HTTP service that allow users to enroll their certificates. Usually, this endpoint is located at /crtsrv and support Negotiate (based on Kerberos) and NTLM authentication.
If the endpoint support NTLM authentication, an attacker can relay a coerced authentication from a remote server to this endpoint in order to retrieve a certificate enrolled by the target computer.
For example, an attacker can coerce NTLM authentication from a DC using a PrinterBug, relay this authentication to the ADCS and retrieve a certificate enrolled with the DC$ identity.
This can be done using ntlmrelayx:
ntlmrelayx.py -t http://${adcsIp}/certsrv/certfnsh.asp -smb2support --adcs --no-http-server
Once the relay is setup, trigger the authentication using an arbitrary method such as the PrinterBug and you will retrieve the Certificate and the Computer Account TGT. Using the S4USelf abuse, you can then compromise the machine.
Persistence
The ADCS can be used to maintain access on the domain. Indeed, if an authentication certificate is requested for a given user by an attacker, the attacker will be able to request TGT for this user as long as the certificat is valid.
It is possible to retrieve certificate with Client Authentication with Certify:
.\Certify.exe find /clientauth
Then, find a certificate that can be enrolled with third party approval (Authorization Signature Required: 0).
Once the certificate is found, generate it with Certipy:
Certify.exe request /ca:${caName} /template:${templateName}